7 ways to structure software requirements and test cases in Jira

There’s a very good reason why more and more teams start using Jira for testing. The interface every Jira user knows well, extended with a dedicated test management app, turns out to be a perfect solution to track the whole software development process in one place. One of such apps, Requirements and Test Management for Jira (RTM), brings the organization of all the testing objects to a higher level.  The tool allows structuring Requirements, Test Cases, Test Plans, Test Executions, and Defects into transparent trees of folders and subfolders. That kind of view not only makes collaboration between all the stakeholders easier but also helps see how particular elements look in the context of the overall project. In this article, we would like to present how you and your team can make the most of that RTM’s functionality. 

When it comes to test management, the most valuable thing is time – and time is exactly what good object structure and work organization can give you and your team. Transparent folders and subfolders speed up defining priorities, assigning tasks to team members, and executing them.

Besides that, testing activities are strongly connected with each other. Well-designed requirements, all covered by related test cases, minimize the number of possible defects in the end and thereby help to economize the time and effort spent on fixing them. Considering the numerous steps involved in the testing process, consistently performing them is essential for ensuring the final product’s quality. So, it’s definitely worth a while to prepare an intuitive list of Requirements and Test Cases. It will later on help with setting up Test Plans and Test Executions.

Having said that, organization of testing elements must be adjusted to the type of the project and particular needs of the team. Below we present some ideas on how to structure requirements and test cases in Jira with RTM‘s tree view.

Requirements and test cases differ when it comes to priority. Some of them have to be done as soon as possible, some can wait, and some are strictly connected to each other so it’s better not to proceed with them before finishing the previous ones. The best way to verify priority is by checking the Priority field, which one sets up on New Requirement and New Test Case creation screens. When they’re ready, the tree view allows to arrange them from Critical to Trivial. That way, you put the most urgent ones on top of the list.

Thanks to ‘drag and drop’ repositioning, modifying the order is simple and fast. Testing is a dynamic process, and so the flexibility of the tools you use is extremely important. If priorities of the objects change throughout analysis or later, during test execution, RTM lets you easily adjust to all those changes and preserve continuous progress.

When the product testing process contains many requirements and test cases, categorization by feature will surely help with keeping track of what’s going on with the project. On the screen below, product requirements are visibly organized in folders and subfolders. After preparing a software requirements specification document, it should be easy to design a similar scheme for test cases. Here we should describe which functionalities of the upcoming product should we test to achieve the project’s goal. Plus, we need to find relations and dependencies between them. In Requirements and Test Management for Jira, it’s a good idea to enter Components and Labels on the Details tab and sort cases based on that information. Doing that at the very beginning prevents the risk of having a mess in the process later.

There are different types of requirements. To describe a project we can start with the basic four

Requirements of each type are equally significant. With the tree structure, it‘s simple to divide them so your list would be transparent for everyone involved. Thanks to appealing data presentation, where the types have their own colors and icons, the organization of items is clear at a glance. On the Relations tab, we can immediately view the number and type of requirements to be covered by test cases. This allows us to generate a comprehensive task list for the testing team members. This kind of structure is best when you test a single product. Otherwise, it may become a bit chaotic during execution.

In RTM, the choice of your project’s requirements and test case structure is wide. You can arrange folders and subfolders however you see fit. In order to make sure that your final product will work in all the environments you want it to, you need to test requirements in every condition individually. That’s why in Test Cases we have a field named RTM Environment. Running test cases in various browsers, on desktop, mobile or tablet is absolutely necessary to avoid any surprises after the product release. In the process of testing on different systems, both requirements and test cases may be similar or even exactly the same. That’s why it’s smart to divide them by environment in order to spot the slight differences.

Another example that shows how useful customized folders are is the possibility to structure requirements and test cases by Assignee. Imagine how much easier it would be for each team member to have a dedicated folder. It will certainly help to save time that they usually spend searching for the cases they should do. What’s more, well-organized objects eliminate the risk of double execution of particular test cases. As we know, a clear definition of people responsible for particular elements of the whole project motivates and speeds up the process.

When organizing Test Cases in RTM it is possible to sort them by testing levels or types. We distinguish four basic levels of test cycles:

If it comes to types of testing, people name up to 9 of them and the most common are:

Managing test cases in Jira with RTM per testing level defines the order of their execution, and organizing per testing type sends a clear message to Jira users about what to focus on in each category.

Even after a major software release, we can expect subsequent updates. The common problem with new versions is the consequences of changes. Modification of one unit can impact the other, not necessarily in a good way. It’s important to control all actions and their results from end to end, especially in such a complex process. That’s why sorting test cases per software version allows preserving the order of the executed changes. It makes it easier to track which version caused possible bugs. When it comes to the organization of the objects by software version, we can distinguish two possible ways:

It’s possible to re-execute the Test Plans in our app. So, if something doesn’t go our way, we can always execute test runs all over again and spot the cause.

Methods we’ve listed before are only a few examples of how can you structure your software requirements and test cases in Jira using Requirements and Test Management for Jira (RTM). The truth is that RTM gives you the possibility to customize the tree view according to your project’s needs. Given that there’s no limit for nesting folders, you can use all the mentioned ways on one view! Make a good plan of collected requirements, assign test cases and bring your software project organization to a higher level.